home *** CD-ROM | disk | FTP | other *** search
/ Games of Daze / Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso / x2ftp / msdos / rules / aas.faq < prev    next >
Internet Message Format  |  1995-04-11  |  22KB

  1. Path: bloom-beacon.mit.edu!news.starnet.net!wupost!waikato!comp.vuw.ac.nz!kauri.vuw.ac.nz!gnat
  2. From: gnat@kauri.vuw.ac.nz (Nathan Torkington)
  3. Newsgroups: rec.arts.int-fiction,news.answers,rec.answers
  4. Subject: Adventure Authoring Systems FAQ
  5. Supersedes: <authoring-systems-faq_787402801@kauri.vuw.ac.nz>
  6. Followup-To: rec.arts.int-fiction
  7. Date: 31 Dec 1994 11:00:04 GMT
  8. Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.
  9. Lines: 472
  10. Approved: news-answers-request@MIT.edu
  11. Distribution: world
  12. Message-ID: <authoring-systems-faq_788871602@kauri.vuw.ac.nz>
  13. Reply-To: Nathan.Torkington@vuw.ac.nz
  14. NNTP-Posting-Host: kauri.vuw.ac.nz
  15. Originator: gnat@kauri.vuw.ac.nz
  16. Xref: bloom-beacon.mit.edu rec.arts.int-fiction:5395 news.answers:32146 rec.answers:9289
  17.  
  18. Archive-name: games/adventure-systems
  19. Maintained-by: Nathan.Torkington@vuw.ac.nz <Nathan Torkington>
  20. Last-changed: Wed Nov 23 14:44:45 NZD 1994
  21.  
  22. ----------------------------------------
  23. Changes:
  24.  * inform
  25. ----------------------------------------
  26.  
  27. This is a list of systems that can be used to author adventure games.
  28. Information about TADS, ADVSYS, ADL, OASYS, INFORM and ALAN can be
  29. found here.
  30.  
  31. Where possible, pointers to existing information (such as books,
  32. magazine articles, and ftp sites) are included here, rather than
  33. rehashing that information again.
  34.  
  35. If you haven't already done so, now is as good a time as any to read
  36. the guide to Net etiquette which is posted to news.announce.newusers
  37. regularly.  You should be familiar with acronyms like FAQ, FTP and
  38. IMHO, as well as know about smileys, followups and when to reply by
  39. email to postings.
  40.  
  41. For more information on interactive fiction in general, pointers to
  42. books and dissertations, and this group's focus, see David Graves'
  43. "Frequently Asked Questions (FAQ)" posting, which appears periodically
  44. in rec.arts.int-fiction.
  45.  
  46. This FAQ is currently posted to rec.arts.int-fiction and news.answers.
  47. All posts to news.answers are archived, and will then possible to
  48. retrieve the last posted copy via anonymous FTP from
  49.     rtfm.mit.edu
  50. as
  51.     /pub/usenet/news.answers/games/adventure-systems
  52. Those without FTP access should send e-mail to
  53.     mail-server@rtfm.mit.edu
  54. with
  55.     "send usenet/news.answers/finding-sources"
  56. in the body to find out how to get archived news.answers posts by
  57. e-mail.
  58.  
  59. This FAQ was mostly written by Nathan Torkington, with numerous
  60. contributions by readers of rec.arts.int-fiction.  Credits appear at
  61. the end.  Comments and indications of doubt are enclosed in []s in the
  62. text.  Each section begins with forty dashes ("-") on a line of their
  63. own, then the section number.  This should make searching for a
  64. specific section easy.
  65.  
  66. If you suffer loss in any way, shape or form from the use of
  67. information in this file, then Nathan Torkington expressly disclaims
  68. responsibility for it.  It's your own damn fool fault if you go broke,
  69. detonate your computer or eat broccoli as a result of anything you
  70. read here.
  71.  
  72. As a final note, this FAQ should be regarded as volatile.  If this
  73. version is more than two months old, you should consider acquiring a
  74. new version.  See the instructions above for details of how to do
  75. this.
  76.  
  77. Contributions, comments and changes should be directed to
  78.     Nathan.Torkington@vuw.ac.nz
  79.  
  80. ----------------------------------------
  81. List of Answers
  82.  
  83. 1    What to look for in a system
  84. 2    Writing your own adventure
  85. 3    TADS
  86. 4    ALAN
  87. 5    ADVSYS
  88. 6    ADL
  89. 7    OASYS
  90. 8    INFORM
  91. 9    Interactive-Fiction FTP Site
  92. Z    Credits
  93.  
  94. ----------------------------------------
  95. 1    What to look for in a system
  96.  
  97.  --> Sample adventures, written using the system.  This will make
  98. learning how to program the system easy.  It will also show you the
  99. workarounds for any clumsiness in the language.
  100.  
  101.  --> The ability to handle non-player characters.  This means that
  102. players should be capable of being addressed, eg "amy, take the cat"
  103. should be a valid command to type.  Players should be capable of
  104. having turns in the background (to allow movement, thieving, etc).
  105.  
  106.  --> The ability to handle events that occur independent of players
  107. actions (often called fuses and daemons).  Fuses are scheduled events,
  108. such has having the bomb detonate three turns after the fuse is lit.
  109. Daemons are routines that are called once every move.
  110.  
  111.  --> Documentation.  You need, at least, a reference page.  Sample
  112. code helps, and a full explanation of the order that routines are
  113. called by the game kernel (eg ADL calls the following for each direct
  114. object: the actor's action, the verb's preaction, the indirect
  115. object's action, the direct object's action, then finally the verb
  116. action.  If any one of these procedures returns a true value, then
  117. that procedure is assumed to have completed the command handling for
  118. that direct object, and processing continues for the next direct
  119. object.  After all the direct objects are handled this way, the room's
  120. action is called and the kernel continues).
  121.  
  122.  --> Distribution mechanism.  Is the game code fully yours to use?  Do
  123. you have to pay a fee for commercial distribution?  For shareware
  124. distribution?  For free distribution?  Are you obligated to offer the
  125. source code to the game interpreter as well as your compiled
  126. adventure?
  127.  
  128.  --> Is it object oriented?  If so, you will probably have an easier
  129. time of writing your adventure -- text adventure worlds lend
  130. themselves to object orientation better than some other forms of
  131. simulation.  Of course, learning the subtleties of the OO method might
  132. be harder than writing your game using a traditional (non-OO) system.
  133.  
  134.  --> Is the game language functional or procedural?  That is, does the
  135. language look like LISP (lots of parentheses) or a kind of cross
  136. between BASIC and C (curly braces {} are a dead giveaway for C
  137. lookalikes).  You might have to learn a whole new programming style if
  138. you write your adventure in a language style that you are unfamiliar
  139. with.
  140.  
  141. ----------------------------------------
  142. 2    Writing your own adventure
  143.  
  144. Dave Librik posted Dave's Quick Guide To Getting Started with TADS,
  145. which was so good that I've generalised it to cover most adventure
  146. systems.
  147.  
  148. Above all else, the key to learning how to write adventures is to
  149. start writing one.  Practice not only makes perfect, but
  150. trial-and-error makes passable too.  You will need the following:
  151.  
  152.  --> a language/kernel reference manual for your adventure system.
  153.      You might have to register your system to get this.
  154.  --> printouts of sample adventures.  Staple each printout, so the
  155.      printouts won't get lost or confused.  Also print out any
  156.      standard libraries that the system comes with (eg adv.t in TADS
  157.      or standard.adl in ADL).
  158.  
  159. Now:
  160.  --> familiarise yourself with the basics of the language.  Subtleties
  161.      (syntax details, daemons, fuses) should be left for later -- just
  162.      the basic ideas of objects, inheritance (if your language is OO),
  163.      printing text.  It might help if you already knew a language in
  164.      the same style (procedural or functional) as the language you
  165.      will have to program in.
  166.  --> read the sample adventures.  Get a feel for how items and rooms 
  167.      are defined.  This step is fairly important -- you will write
  168.      most of your adventures by strategically stealing the way someone
  169.      else has written theirs (software professionals call this "code
  170.      reuse" -- we call it laziness).
  171.  --> make a copy of one of the simpler sample adventures.  Take out
  172.      all the stuff specific to that adventure (rooms, players,
  173.      objects, etc) and just leave the verbs, the initialisation code,
  174.      and the definition of the player's character.  Now start writing
  175.      your own adventure.  Start simple -- a couple of rooms and some
  176.      objects to take.
  177.  --> add more complicated things.  For ideas of things to add, it
  178.      helps to have played some adventures.  Try adding code for doors,
  179.      containers, other actors, new verbs, fancy verbs that need
  180.      indirect objects.  Use the sample adventures that came with the
  181.      system as a reference for using things.
  182.  --> if the sample adventure you modified included standard code for
  183.      players or startup (std.t in TADS), then include those libraries
  184.      and customise them to your taste (you should have no trouble
  185.      reading and understanding the code by now).  Add any of your own
  186.      initialisation code to this.
  187.  --> when you want to start making significant changes to the
  188.      behaviour of the adventure, you will have to change any standard
  189.      libraries that your adventures includes (standard.adl in ADL,
  190.      adv.t in TADS).  Whenever you make a change, comment at the top
  191.      of the file why you make the change, and exactly what you
  192.      changed.  This is so that when your later adventures need any of
  193.      the features you have added, it will be easy to add them.  It
  194.      also helps when newer releases of the adventure system arrive --
  195.      you can make the changes to the new standard library with minimal
  196.      hassle.
  197.  --> now realise that what you have written is a practice game.  It
  198.      probably wasn't well laid out, or well planned, or even
  199.      consistent.  To write your Real Adventure, you will have to go
  200.      through some serious Design and Implementation.
  201.  
  202. The classic Colossal Cave adventure has been rewritten in TADS by Dave
  203. Baggett <dmb@ai.mit.edu> and is available in source from the IF
  204. archive (see Section 9) in the directory
  205.     if-archive/games/adventions/others/ccr.tar.Z
  206. There is also an INFORM version which Graham Nelson derived from the
  207. TADS sources.
  208.  
  209. The documentation to INFORM (see section 8) contains a wealth of
  210. material relevant to designing adventure games under any system.  This
  211. is highly recommended for those wishing to write their own games.
  212.  
  213. ----------------------------------------
  214. 3    TADS
  215.  
  216. TADS stands for "Text Adventure Development System".  It is available
  217. for MSDOS, Atari ST, Macintosh, Sun, SGI, Linux, DEC/MIPS, and NeXT
  218. computers at the moment.  It is available via anonymous FTP as
  219.     ftp.gmd.de:if-archive/programming/tads/
  220. The latest version, TADS 2.1, features virtual memory, expanded C-like
  221. syntax, improved documentation and an improved debugger.
  222.  
  223. TADS is released by High Energy Software, and is shareware.  Shareware
  224. games can (and have) been written using TADS, and commercial
  225. distribution of games written using TADS seems allowable.  TADS
  226. consists of a compiler (which converts the source code to adventures
  227. into TADS game code) and an interpreter (which reads the TADS game
  228. code produced by the compiler and lets users play the game).
  229.  
  230. Registered users get a form of the interpreter which can be combined
  231. with the game code file to form a single executable for distribution.
  232. The interpreter is licensed for shareware use, you don't have to pay a
  233. penny if you distribute your games via shareware.  If you plan to sell
  234. it commercially, contact Mike Roberts for information on getting the
  235. rights.
  236.  
  237. The TADS language is declarative and object-oriented.  It appears very
  238. C-like, and the syntax shouldn't be too difficult to learn by people
  239. who know C or Pascal.  The language provides a basic syntax, some text
  240. manipulation and support for object-oriented programming.  The
  241. interpreter provides parsing, question-and-response I/O format, and
  242. activation of the appropriate methods in objects depending on what the
  243. player types.  The language has support for actors, fuses and daemons.
  244.  
  245. TADS comes with the source to a trivial adventure, and source to an
  246. Infocom quality game ("Ditch-Day Drifter").  On registration of the
  247. package, a manual can be obtained.  The manual for v1.* is very good
  248. (although it doesn't explain well the contents of the standard library
  249. file, adv.t).  The v2.1 manual is apparently twice the size of v1.
  250.  
  251. The prices for versions < 2.0 are:
  252.  TADS shareware fee: 25.00
  253.    Includes printed TADS Author's Manual, the
  254.    current TADS software on specified media,
  255.    plus the source code for "Ditch Day
  256.    Drifter," a complete sample game.
  257.  Deep Space Drifter: 10.00
  258.    Includes "Deep Space Drifter" on the disk
  259.    media specified above, plus a complete map
  260.    of the game and the DSD Hint Book.
  261.  California residents please add 7% sales tax.
  262.  
  263. The price of v2.1 is US$40 (+ California sales tax for California
  264. residents, $3 for shipping and handling within the US and Canada, or
  265. $8 for international air mail).  If you register "Deep Space Drifter"
  266. at the same time, the total is only US$50 (plus sales and shipping).
  267. For more information, contact:
  268.  --> BBS:        415 493 2420 (set modem to 14400-N-8-1)
  269.  --> CompuServe: 73737,417
  270.  --> GEnie:      M.ROBERTS10
  271.  --> Internet:   73737.417@compuserve.com
  272.  --> US Mail:    High Energy Software, PO Box 50422, Palo Alto, CA
  273. 94303.
  274.  
  275. Dave Baggett has placed his WorldClass library, a free TADS class
  276. library which entirely replaces ADV.T, on the IF archive (see section
  277. 9) as
  278.     ftp.gmd.de:/if-archive/programming/tads/worldclass
  279. This library is about three times the size of ADV.T and is
  280. correspondingly more powerful.
  281.  
  282. ----------------------------------------
  283. 4    ALAN
  284.  
  285. The Alan System is a special purpose language for creating interactive
  286. fiction or text adventures. It consists of a compiler which compiles
  287. Alan source to an intermediate form and an interpreter that interprets
  288. such an intermediate form.
  289.  
  290. The Alan language was designed to give the maximum functionality from
  291. as little code-writing as possible.  This means:
  292.  --> the system provides default behaviour for many things (which the
  293.      author can override).
  294.  --> the system directly supports locations, objects, actors and
  295.      other concepts natural to the domain of interactive fiction.
  296.  --> the author can extend the allowable input of the player, and
  297.      connect actions to that input.
  298.  
  299. It is also a safe language in the sense that extensive compile-time
  300. checking makes it nearly impossible to produce a game that crashes or
  301. behaves inconsistently.
  302.  
  303. The language is declarative and very close to English. It supports
  304. fuses and daemons by use of events, and is object-inspired (all
  305. declarations are local to entities, but no inheritance).
  306.  
  307. The Alan System is request-ware. The complete system is available
  308. without charge through electronic mail.  Send a message with a single
  309. line:
  310.     SEND INFO
  311. to
  312.     alan-request@softlab.se
  313. for more information.
  314.  
  315. The complete distribution includes the compiler, the documentation, a
  316. 100+ page manual in plain text and postscript versions, some examples
  317. and the interpreter with debugging support.  The interpreter can be
  318. redistributed with your games, so this seems to open the way for
  319. commercial and shareware release.
  320.  
  321. The manual is available from the IF archive (see Section 9) in the
  322. directory
  323.     if-archive/programming/alan/manual.zip
  324.  
  325. The current version of Alan is 2.4 which runs on Sun/UNIX, Amigas, PCs
  326. (MSDOS and OS/2) and VAX/VMS.  A major revision of the manual is
  327. planned, and a larger game is also being worked on for release.
  328.  
  329. The authors may be contacted at:
  330.  
  331.     alan-request@softlab.se        pseudo-mail-server for deliveries
  332.     thoni@softlab.se
  333.     gorfo@ida.liu.se
  334.  
  335. ----------------------------------------
  336. 5    ADVSYS
  337.  
  338. ADVSYS (ADVenture SYStem) was written by David Betz, and the latest
  339. version (1.3) is based on the 1986 release of 1.2 which seems more
  340. prolific.  This package consists of LaTeX and ASCII documentation, C
  341. source code for the compiler and interpreter, and the source code for
  342. several sample adventures (as well as a demonstration library).  It
  343. was written up in Byte magazine [reference here].
  344.  
  345. The language is LISP-like, and object-oriented.  The game has no
  346. knowledge of the difference between actors, objects, locations, etc --
  347. all this must be present in the game code.  As such, the runtime
  348. library is rather more complex than might be desired.  Actors, fuses
  349. and daemons can all be implemented easily.
  350.  
  351. There is [somewhere] a library of code developed by the (now-defunct)
  352. ADVSYS mailing list.  This provides rather better code than the
  353. library distributed with ADVSYS, and includes containers and limits to
  354. containment.
  355.  
  356. The documentation says "Permission is hereby granted for unrestricted
  357. non-commercial use".  You might have to contact David Betz to ask
  358. about commercial and shareware distribution.
  359.  
  360. ADVSYS was posted to comp.sources.games, and appeared in volume 2.  It
  361. can, therefore, be found on any FTP site that archives it.  Two such
  362. FTP sites are:
  363.     ftp.uu.net:/usenet/comp.sources.games/volume2/advsys
  364.     wuarchive.wustl.edu:/usenet/comp.sources.games/volume02/advsys
  365.  
  366. An ANSI C version is available, on the IF Archive site (see section 9).
  367.  
  368. ----------------------------------------
  369. 6    ADL
  370.  
  371. ADL (Adventure Design Language) was written by Ross Cunniff and Tim
  372. Brengle.  The package posted to comp.sources.games consists of plain
  373. ASCII documentation, C source for a compiler, interpreter and
  374. debugger, and several sample adventures (ranging from the complex to
  375. the very simple) which illustrate the various features of ADL.
  376.  
  377. ADL is a declarative, semi-object-oriented language.  It has the
  378. concept of methods (procedures that are attached to objects) but not
  379. inheritance.  This means that an object-oriented style of programming
  380. will be rather inhibited.
  381.  
  382. The language recognises actors, locations and objects as being
  383. distinct.  Fuses and daemons are supported in the language.  A
  384. standard library comes with the package, that gives a firm foundation
  385. to write games on.
  386.  
  387. The documentation is very close to being excellent, and contains a
  388. full language reference.  The documentation doesn't appear to contain
  389. any guide to distribution of anything but the source code.  Therefore
  390. it may be legal to distribute the compiled interpreter with your game.
  391. For more information, you should contact the authors at:
  392.  
  393.         USMAIL: Ross Cunniff
  394.                 636 La Grande, #7
  395.                 Sunnyvale, CA 94087
  396.  
  397. ----------------------------------------
  398. 7    OASYS
  399.  
  400. OASYS stands for Object-Oriented Adventure System.  It was distributed
  401. in comp.binaries.ibm.pc in 1992, and is available from any FTP site
  402. which archives cbipc.  It was written by Russell Wallace, who is
  403. reachable via e-mail as RWALLACE@vax1.tcd.ie.
  404.  
  405. The package has documentation, two sample adventures, C source for the
  406. compiler and interpreter, and MS-DOS binaries for the compiler and
  407. interpreter.  The source is missing an include file (Russell will
  408. provide it on request) and shouldn't be very difficult to port to non
  409. MS-DOS systems.
  410.  
  411. The language is declarative, and (not really) object-oriented.  The
  412. major limitation of the parser is that it forces the player to type
  413. the adjectives along with the noun ("ceramic key" must be typed, even
  414. if there are no other keys accessable).  This may be fixed later.
  415.  
  416. Actor support is provided, and players can issue commands to other
  417. actors.  [fuses?  daemons?]
  418.  
  419. There don't appear to be any legal restrictions, so you can probably
  420. distributed compiled interpreters with your commercial/shareware/free
  421. games.
  422.  
  423. ----------------------------------------
  424. 8    INFORM
  425.  
  426. INFORM was written by Graham Nelson at Oxford University, UK.  It is a
  427. compiler that produces Infocom story files.  There are many
  428. public-domain interpreters for these files, available from the
  429. Interactive Fiction archive site.
  430.  
  431. The compiler is written in ANSI C, and is freely available (but not
  432. public domain).  It produces version-3 files from a fairly C-like
  433. source language, and can produce version-5 files as well (an important
  434. innovation since they are twice as large --- Trinity-sized instead of
  435. Zork-1-sized).
  436.  
  437. The manuals have been hugely improved for Inform 5.4, and are now
  438. divided into four:
  439.  
  440.  
  441.   The Inform Designer's Manual
  442.     - entirely rewritten as a tutorial with detailed appendices for
  443.       reference, many exercises with solutions provided and an index;
  444.   The Inform Technical Manual
  445.     - low-level features, porting notes, modification history;
  446.   The Specification of the Z-Machine
  447.     - everything currently known about Infocom's run-time format, which
  448.       we believe is now completely deciphered, and Inform assembly language;
  449.   The Craft of Adventure
  450.     - a short book about writing adventure games, and not about any system.
  451.  
  452. A new edition of the last of these is still being revised, but the
  453. first three are available in both TeX and PostScript form (properly
  454. typeset and coming to about 105, 20, 40 pages respectively).  The
  455. Designer's Manual also comes in a plain ASCII text version.
  456.  
  457. There are now four example games: Advent (the Colossal Cave port,
  458. which is quite large); Adventureland (an easy example, the Scott Adams
  459. classic); Toyshop (a game with few rooms but very many exotic objects,
  460. to demonstrate unusual features and programming tricks), and Balances
  461. (a pastiche of Infocom's "Enchanter" trilogy, which demonstrates how
  462. to program the parser in cunning ways).  These all come with source.
  463.  
  464. INFORM is genuinely free, and the rights to a game it produces belong
  465. to the author of the game.
  466.  
  467. ----------------------------------------
  468. 9    Interactive-Fiction FTP Site
  469.  
  470. The FTP site ftp.gmd.de:/if-archive contains most, if not all,
  471. of the software mentioned here as well as interpreters for Infocom
  472. games, source and binaries for many other games and sundry information
  473. files too numerous to mention.
  474.  
  475. ftp.gmd.de:/if-archive is mirrored in
  476. wuarchive.wustl.edu:/doc/misc/if-archive.
  477.  
  478. The latest FAQ is stored here as
  479.         if-archive/info/authoring-systems.FAQ and as
  480.         if-archive/programming/general-discussion/authoring-systems.FAQ
  481.  
  482. ----------------------------------------
  483. Z    Credits
  484.  
  485. Nathan Torkington <Nathan.Torkington@vuw.ac.nz>, David Librik
  486. <librik@cory.Berkeley.EDU>, Dave Baggett <dmb@case.ai.mit.edu>, Thomas
  487. Nilsson <thoni@ida.liu.se>, Graham Nelson <nelson@vax.ox.ac.uk>,
  488. Volker Blasius <blasius@gmd.de> and the documentation for the various
  489. systems mentioned here.
  490.